]> dgit.raspbian.org Git - gnome-shell.git/commit
extensionUtils: Create and allow access to a new "extension" object
authorJasper St. Pierre <jstpierre@mecheye.net>
Tue, 31 Jan 2012 01:58:29 +0000 (20:58 -0500)
committerJasper St. Pierre <jstpierre@mecheye.net>
Tue, 7 Feb 2012 21:00:37 +0000 (16:00 -0500)
commita622aba7eb7ce9ee7f423ec99f480ae6cffc63e8
tree18b3773b3d93c94916ca44bb9ae4c88504719fb3
parent831099cca5468f5fe6cca8e1949d8b00d598ad8d
extensionUtils: Create and allow access to a new "extension" object

The "extension" object is what I previously called the "helper" object.
It contains the extension importer object as well as the metadata object.
Things that were previously added on to the metadata (state, path, dir, etc.)
are now part of this new "extension" object.

With the new importer changes brought on by the extension prefs tool,
extensions are left without a way to import submodules at the global scope,
which would make them rely on techniques like:

  var MySubModule;

  function init(meta) {
      MySubModule = meta.importer.mySubModule;
  }

That is, there's now a lot more meaningless boilerplate that nobody wants
to write and nobody wants to reivew.

Let's solve this with a few clever hacks.
Allow extensions to get their current extension object with:

  let extension = imports.misc.extensionUtils.getCurrentExtension();

As such, extensions can now get their own extension object before the
'init' method is called, so they can import submodules or do other things
at the module scope:

  const MySubModule = extension.imports.mySubModule;
  const dataPath = GLib.build_filenamev([extension.path, 'awesome-data.json']);

https://bugzilla.gnome.org/show_bug.cgi?id=668429
js/extensionPrefs/main.js
js/misc/extensionUtils.js
js/ui/extensionSystem.js
js/ui/lookingGlass.js
js/ui/shellDBus.js